Некоторые из вас знают, что VMware больше не является сервис-провайдером публичных облаков со своей собственной железной инфраструктурой (этот бизнес был продан французской OVH), но у нее есть две облачных инициативы с партнерами лидирующих облачных решений - VMware vCloud on AWS и VMware vCloud on Azure.

Блогер Ryan Kelly написал интересный пост, в котором он сравнивает оба решения - и выводы явно не в пользу vCloud on Azure. Давайте посмотрим:

1. Управление.

VMware vCloud on AWS - это полноценный vSphere Client, к которому вы привыкли в вашем датацентре. Все те же средства автоматизации операций и скрипты PowerCLI работают в облаке без необходимости их доработки.

VMware on Azure имеет собственную консоль управления, а также свой API, что потребует адаптации ваших решений и сценариев PowerCLI. Таким образом, вам нужно будет поддерживать 2 набора рабочих процессов, при этом персонал должен иметь два набора умений для этого, что обходится дороже и неудобно.

2. Миграция рабочих нагрузок в облако и обратно.

vMotion между онпремизной инфраструктурой и облаком происходит без изменения IP-адреса, используется растянутый кластер под контролем решения NSX. Серверы управления vCenter объединены режимом Linked Mode.

В облаке vCloud on Azure миграция vMotion не поддерживается, нужно копированием переносить виртуальные машины, а IP-адрес в любом случае поменяется при перенесении ВМ в облако (кстати, обратного пути миграции нет):

3. Стоимость решения.

Для VMware vCloud on AWS используется модель Host-based pricing, то есть покупаете нужное количество хостов, а все остальные лицензии (включая хранилища кластера vSAN) уже включены в цену. На хосте вы можете создать сколько угодно и какие угодно виртуальные машины. Подробности в прайс-листе.

Для vCloud on Azure лицензирование идет по инстансам виртуальных машин, а за хранилище надо платить отдельно. Вот прайс-лист.

4. Катастрофоустойчивость на уровне площадок.

vCloud on AWS обеспечивает полную связность площадок, прозрачную для пользователей. С помощью технологии Host based replication образ ВМ реплицируется между облаком и онпремизным сайтом, шарится общий IP-адрес. В случае сбоя на одной из площадок, для восстановления работоспособности сервиса нужно будет только нажать на кнопку.

При восстановлении машины в облако Azure нужно будет ее как-то скопировать туда, зарегистрировать и сконфигурировать (это будет новая ВМ, у которой другое виртуальное аппаратное обеспечение и драйверы). Также могут возникнуть сложности с бэкапом восстановлением залоченных файлов, которые не берет система резервного копирования на уровне файлов.

Из описанных пунктов может следовать еще несколько неудобств, но даже перечисленных уже достаточно, чтобы не покупать VMware vCloud on Azure. Непонятно пока, кому такая гибридная инфраструктура подойдет - разве что совсем маленьким компаниям, не собирающимся расти.

Как вы знаете, некоторое время назад были обнаружены серьезные уязвимости в процессорах компании Intel, условно называемые Meltdown и Spectre. Вскоре после их обнаружения многие производители выпустили обновления микрокода оборудования, многие из которых оказались неготовыми к эксплуатации в производственной среде (происходили неожиданные перезагрузки, падала производительность и появлялись другие эффекты).

VMware тогда тоже выпустила обновления для VMware ESXi и vCenter, закрывающие потенциальные угрозы, но через несколько дней была вынуждена отозвать их обратно ввиду тех же самых эффектов.

Теперь, наконец, вышло обновление VMware vCenter Server Appliance 6.5 Update 1f, содержащее исправления для серверов управления на базе виртуального модуля с Photon OS на борту, исправляющее следующие дыры в безопасности:

• Bounds-check bypass (уязвимость Spectre-1, CVE-2017-5753)
• Rogue data cache load issues (уязвимость Meltdown, CVE-2017-5754)

Надо отметить, что уязвимость Spectre-2 (Branch target injection - CVE-2017-5715) по-прежнему не исправлена в данном релизе.

Патч VMware vCenter 6.5 Update 1f можно загрузить с VMware Patch Portal (VMware-VCSA-all-6.5.0-7801515.iso):

В процессе апдейта будут обновлены следующие пакеты:

• linux 4.4.110-2
• libgcrypt 1.7.6-3
• c-ares 1.12.0-2
• ncurses 6.0-8
• libtasn1 4.12-1
• wget 1.18-3
• procmail 3.22-4
• rsync 3.1.2-4
• apr 1.5.2-7

Также помимо VMware vCSA патч доступен и для решения vSphere Integrated Containers 1.3.1. На данный момент матрица выхода апдейтов фикса Meltdown и Spectre выглядит весьма удручающе (более подробно - вот тут):

Пропатчить VMware vCSA можно также через GUI из дефолтного репозитория обновлений продукта.

Ну и мы все еще ждем обновления для хостов VMware ESXi, которые до сих пор в статусе "Patch Pending".

Гостевой пост нашего партнера - сервис-провайдера ИТ-ГРАД, предоставляющего услугу аренды виртуальных машин VMware из облака.

Облачные технологии не перестают охватывать новые направления бизнеса, завоевывая рынки и укрепляя позиции в разных сферах. И вряд ли найдется такая область, применив к которой облачный подход было бы невозможно заметить положительные результаты. Взять, к примеру, автомобильную отрасль: только в этом направлении облако решает целый ряд непохожих друг на друга задач. Каких именно — расскажем в этой статье.

BelkaCar — облачный каршеринг нового формата

Каршерингом сегодня никого не удивить, ровно так же, как не удивить тем, что сервисы для реализации такого рода услуг работают из облака хостинг-провайдера. Это и понятно, ведь облако — надежная площадка, которой отдают предпочтение сотни тысяч компаний по всему миру. Так, сервис BelkaCar, предлагающий решение для краткосрочной аренды автомобилей в Москве, уже не первый год использует облачную инфраструктуру, которая решает важнейшую для компании задачу, связанную с масштабированием. К тому же облако позволяет быстро адаптироваться под меняющуюся нагрузку и экономить на поддержке.

При этом архитектурная составляющая сервиса заточена на использование нескольких логических модулей, каждый из которых отвечает за выполнение определенной задачи. К ним относятся модули работы с пользователями, арендой, телематикой, биллингом и прочее. Для получения наилучшего результата каждый модуль максимально инкапсулируется. Такой подход снимает прямую зависимость модулей друг от друга и упрощает дальнейшую доработку.

Как отмечают в компании, облако без особых усилий поддерживает выбранную схему, справляясь с задачей горизонтального масштабирования, и позволяет с легкостью увеличивать количество используемых ресурсов для повышения производительности.

Tata Motors, облачные порталы и ямы на дорогах

Крупнейшая автомобилестроительная компания Tata Motors и ее «дочки» Jaguar и Land Rover являются активными потребителями облака, поскольку используют облачную площадку в качестве технологической основы. Так, Tata Motors в своей работе ориентируется на специализированные порталы, вынесенные в облако провайдера, которые помогают владельцам автопарков отслеживать транспортные средства в режиме реального времени. Такой подход позволяет сократить сроки реализации инфраструктурных проектов и повысить скорость работы необходимых для бизнеса сервисов... Читать статью далее->>.

Как вы знаете, у компании VMware есть такой продукт Workspace ONE, который позволяет привести в соответствие корпоративным политикам инфраструктуру клиентских устройств (телефонов, планшетов, настольных ПК) с помощью купленной когда-то технологии AirWatch unified endpoint management (UEM). Помимо средств защиты и соблюдения комплаенса, Workspace ONE дает пользователям средства совместной работы и Single Sign-On для приложений, а работодателю - средства контроля над устройствами пользователей (соблюдение комплаенса, то есть корпоративных политик).

На днях команда AirWatch опубликовала заметку о новых возможностях обновленной версии Workspace ONE Mobile Apps Suite. Теперь, как вы видите на картинке выше, в состав Workspace ONE войдут следующие компоненты:

• People Search - это новый компонент, который позволяет получать информацию о людях в вашей организации, включая контактные данные, должность и иерархию подчинения. Очень удобно для тех, кто сидит на митинге и хочет узнать, что за хрены там тоже собрались. Если вы уже имеет в составе решений VMware Indentity Manager, то интегрировать People Search будет очень просто. Данные об организационной структуре будут браться из Active Directory, а какие поля будут видны пользователям - определяет администратор.

• VMware Boxer - это решение для почтовых сервисов Gmail, Exchange, Outlook, Yahoo, Hotmail, iCloud и Office 365 для протоколов IMAP и POP3, которое позволяет объединить все на платформе одного почтового клиента, интегрировав туда поддержку таких приложений, как Dropbox или Box.

Проще говоря, это почтовый Enterprise-клиент. В новой версии VMware Boxer будет улучшен механизм нотификаций для пользователей (нижний блок на скриншоте выше), а также добавлена поддержка IBM Lotus Notes.

• VMware Browser - это компонент для защищенного (без необходимости развертывать VPN) доступа к веб-содержимому корпоративной сети и интернета с возможностью ограничения просматриваемого и загружаемого контента. Теперь с помощью этого защищенного политиками браузера можно переходить по ссылкам из QR-кодов.

• Content Locker - это средства VMware, позволяющие доставлять контент (фото и видео) с устройств пользователей в защищенные корпоративные репозитории. Например, с помощью Content Locker врач может отправлять файлы в хранилище больницы, которое защищено в соответствии с отраслевыми и государственными требованиями (персональные данные категории К1). В новой версии Content Locker появились улучшения рабочего процесса по фотографированию и отсылке контента на защищенные серверы (включая добавление и обработку метаданных).

Также в VMware Workspace ONE был существенно улучшен процесс онбординга пользователей (то есть их включение в инфраструктуру приложений и сервисов), более детально об этом написано тут.

Более подробная информация о решении VMware Workspace ONE изложена на специальном портале.

Компания VMware выпустила обновленную версию документа "Network Ports in VMware Horizon Cloud Service", в котором приведены диаграммы портов и соединений сервиса VMware Horizon Cloud. Данные диаграммы нужны для корректной настройки фаерволов, а также отслеживания сетевых коммуникаций между компонентами (стрелками в документе показаны их направления).

В документе приведены 3 архитектуры VMware Horizon Cloud, которые рассматриваются в различных его разделах:

• Horizon Cloud with Hosted Infrastructure with external connectivity
• Horizon Cloud with Hosted Infrastructure with internal connectivity
• Horizon Cloud on Microsoft Azure

Диаграммы работают в интерактивном режиме, то есть вы можете выбрать интересующий вас компонент (например, протокол Horizon) и "провалиться" глубже для подробного изучения его соединений. Для этого нужно PDF скачать, а не просматривать его в браузере.

Помимо диаграмм присутствуют также таблицы с описанием источника и назначения соединения, вида протокола, номерами портов и описания - для чего эта коммуникация нужна.

Также в документе рассматриваются такие продукты, как VMware Identity Manager, VMware App Volumes, VMware ThinApp и другие решения, использующиеся в инфраструктуре Horizon. Соответственно, его можно использовать и как референс при планировании и развертывании онпремизной или облачной инфраструктуры Horizon Cloud.

Скачать документ Network Ports in VMware Horizon Cloud Service можно по этой ссылке. Также посмотрите наш пост "Диаграмма портов и соединений VMware Horizon 7 - обновления".

В конце января компания VMware выпустила существенное обновление своего клиента на базе технологии HTML5 для управления виртуальной инфраструктурой VMware vSphere. На днях вышел еще один апдейт - VMware vSphere Client 3.34, в котором также появилось немало всего нового.

Давайте посмотрим на последние фичи vSphere Client версии 3.34:

• Визуализация топологии виртуальных коммутаторов (см. на скриншоте выше).
• Возможность пакетного создания виртуальных адаптеров VMkernel на распределенной группе портов vDS.
• Действие по привязке лицензи (Assign License) на вкладке License Assets.
• Сообщение об устаревающих лицензиях vCenter.
• Изменение настроек виртуальных сервисов vApp.
• Включение и изменение настроек vApp для его виртуальных машин.
• Перемещение сетей (networks) и распределенных коммутаторов в новые папки типа network в инвентори.
• Пакетная привязка физических сетевых адаптеров к аплинкам в мастере "Add and Manage Hosts" на распределенном коммутаторе.
• Пакетная привязка портов VMkernel к порт-группам "Add and Manage Hosts" на распределенном коммутаторе.
• Отображение дополнительной информации, такой как состояние питания и информации Quiesce/memory для снапшотов виртуальных машин.

Загрузить VMware vSphere Client 3.34 можно по этой ссылке.

Иногда у администраторов VMware vSphere появляется проблема на сервере VMware vCSA (виртуальный модуль vCenter), когда дисковое пространство в разделе /var/log забивается под завязку. Например, если выполнить команду ls, то получим вот такую картину:

vcsa-01:/var/log # ls -lh

total 4.6G

-rw-r----- 1 dnsmasq dnsmasq  17M Feb  4 08:32 dnsmasq.log

-rw-r----- 1 dnsmasq root    844M Jan 28 07:45 dnsmasq.log-20180128

-rw-r----- 1 dnsmasq dnsmasq 3.7G Feb  2 16:19 dnsmasq.log-20180204

Здесь мы видим целых 4,6 ГБ логов! Такая ситуация - не редкость, поэтому иногда нужно поменять настройки заполнения и ротации логов, чтобы раздел не забивался. В данном случае растет лог dnsmasq - кэша сервера DNS и DHCP на сервере vCSA (подробнее тут).

Вот тут мы уже писали о том, как сменить еженедельную ротацию на ежедневную, а теперь немного более подробно посмотрим на проблему. По этому вопросу есть специальная статья VMware KB - "Root partition on the vCenter Server Appliance is full due to dnsmasq.log files".

В качестве решения предлагается отредактировать файл /etc/logrotate.d/dnsmasq до следующего состояния:

/var/log/vmware/dnsmasq.log {

nodateext # добавляем эту строчку

daily # меняем со значения weekly

missingok

notifempty

compress # меняем со значения delaycompress

maxsize 5M # добавляем эту строчку

rotate 5 # добавляем эту строчку

sharedscripts

postrotate

[ ! -f /var/run/dnsmasq.pid ] || kill -USR2 `cat /var/run/dnsmasq.pid`

endscript

create 0640 dnsmasq dnsmasq

}

Кстати, размещение файла логов можно изменить в файле /etc/dnsmasq.conf, для этого надо поменять вот эту строчку:

log-facility=/var/log/vmware/dnsmasq.log

Сам же данный конфигурационный файл рекомендуется сделать таким:

listen-address=127.0.0.1

bind-interfaces

user=dnsmasq

group=dnsmasq

no-negcache

no-hosts

log-queries

log-facility=/var/log/vmware/dnsmasq.log

domain-needed

dns-forward-max=150

cache-size=8192

neg-ttl=3600

После этого перезапускаем сервис dnsmasq:

vcsa-01:~ # service dnsmasq restart

Shutting name service masq caching server

Starting name service masq caching server

Блогер David Pasek опубликовал интересный пост, касающийся ограничения виртуальных машин и их виртуальных дисков по числу операций ввода-вывода. Смысл его в том, что автор, являющийся ярым сторонником обеспечения QoS на уровне виртуальных дисков, настоятельно рекомендует применять ограничения IOPS limit к виртуальным дискам машин, которые потенциально могут выесть много полосы ввода-вывода.

Сейчас ограничивать виртуальные машины по IOPS можно как на уровне виртуальных дисков на томах VMFS/RDM/NFS, так и на уровне томов VVols. Многие системы хранения оперирует понятием логического тома LUN, на котором размещается один том VMFS. Как правило, LUN - это логический том, что значит, что несколько LUN могут размещаться на одной физической группе дисков:

Таким образом, виртуальные машины, потребляющие много IOPS от хранилища (он называет их "noisy neighbor") могут существенно замедлить работу других производственных систем.

Поэтому для таких машин требуется создавать ограничения IOPS limit, которые можно задать для виртуального диска в опциях машин, либо привязать к VMDK диску политику с ограничениями по IOPS.

Например, в vSphere Web Client создаем новую VM Storage Policy с ограничениями IOPS limit for object:

А далее привязываем эту политику к диску VMDK в настройках ВМ:

Тут же в настройках можно задать значение в поле Limit-IOPs, если не выбирать политику.

Именно ограничение по IOPS делает поведение инфраструктуры хранения для виртуальных машин предсказуемым и управляемым. Ограничения по вводу-выводу позволят обеспечить минимально приемлемый уровень обслуживания для виртуальных машин, которым требуются ресурсы хранилища, с гарантией того, что остальные системы не съедят все доступные IOPS.

Ну и в заключение несколько аспектов данного рода ограничений:

• Команды ввода-вывода (IO) нормализуются к блоку 32 КБ, то есть команда в 128 КБ будет преобразована в 4 IO.
• IOPS limit не влияет на операции SVmotion (миграция хранилища), XVmotion (миграция машин без общего хранилища) и клонирование ВМ.
• IOPS limit применяется только ко вводу-выводу гостевой ОС и не затрагивает операции с самим диском VMDK и его swap-файлами.
• Если у машины несколько лимитов по IOPS для дисков на одном датасторе, то эти лимиты складывают и применяются для всей ВМ на этом датасторе в целом. Если же диски находятся на разных хранилищах, то тут уже действуют правила для каждого из групп дисков.
  • Например, если у каждой из 4 дисков машины на одном датасторе стоит лимит 100 IOPS, то для всей машины будет совокупный лимит 400. То есть, если три VMDK едят по 10 IOPS каждый, то четвертый диск сможет съесть максимум 370 IOPS.
  • А вот для NFS-хранилищ все работает несколько иначе - если у каждого из 4 дисков на одном датасторе стоит лимит 100 IOPS, то сколько бы ни потребляли остальные диски, для каждого из дисков будет применен максимальный лимит 100.
• Полная информация об ограничении ввода-вывода для виртуальных машин приведена в KB 1038241.

Также рекомендуем почитать нашу статью "VMware Storage I/O Control (SIOC) - как это работает на практическом примере".

На днях вышел магический квадрант Gartner Magic Quadrant for Hyperconverged Infrastructure (HCI), отражающий ситуацию на рынке гиперконвергентной инфраструктуры. Это такая инфраструктура, где все ее вычислительные ресурсы, системы хранения и сети виртуализованы и собраны в единую интегрированную сущность и управляются из одной точки.

Компания VMware заняла в этом квадранте место в тройке лидеров (надо отметить, что учитывались не только онпремизные, но и облачные HCI-инициативы), расположившись рядом со своей материнской компанией Dell EMC.

Напомним, что Magic Quadrant используется для оценки поставщиков какого-либо сегмента рынка информационных технологий, где Gartner использует две линейные прогрессивные экспертные шкалы:

• полнота видения (completeness of vision)
• способность реализации (ability to execute)

Каждый поставщик, попавший в рамки рассмотрения для исследуемого сегмента рынка, оценивается по этим двум критериям. При этом, полнота видения откладывается на оси абсцисс, способность реализации — на оси ординат. Каждый поставщик, таким образом, оказывается в одном из четырёх квадрантов плоскости, называемых:

• Лидеры (leaders) — поставщики с положительными оценками как по полноте видения, так и по способности реализации.
• Претенденты (сhallengers) — поставщики с положительными оценками только по способности реализации.
• Провидцы (visionaries) — поставщики с положительными оценками только по полноте видения.
• Нишевые игроки (niche players) — поставщики с отрицательными оценками по обоим критериям.

Кстати, Magic Quadrant по серверной виртуализации больше не публикуется (вы, возможно, заметили, что его не было в 2017 году) - так как Gartner считает этот рынок зрелым, там все и так всем понятно, поэтому никакой аналитической работы проводить не нужно.

Стоит отметить, что попадание в квадрант лидеров для VMware как для поставщика чисто программных решений - большое достижение. Сейчас VMware использует аппаратные решения 15 партнеров, чтобы предлагать HCI-решения пользователям. Пример такой архитектуры - VCE и Vblock. Кстати, Dell EMC, в свою очередь, продвигает решения VxRail и VxRack, в состав которых входит решение для создания кластеров отказоустойчивых хранилищ vSAN.

Кстати, если говорить о серверных HCI-решениях, то VMware уже сейчас поддерживает более 400 моделей серверов (на картинке от мая 2017 года было еще 250 моделей) в рамках программы ReadyNode для построения кластеров vSAN.

Скачать отчет Gartner Magic Quadrant for Hyperconverged Infrastructure (HCI) можно по этой ссылке.

В конце прошлого года VMware сделала доступным для загрузки обновленную версию решения для обеспечения сетевой безопасности VMware vRealize Network Insight 3.6. Напомним, что о версии vRNI 3.5 мы писали осенью прошлого года в рамках анонсов VMworld 2017.

Давайте посмотрим, что нового появилось в vRNI 3.6:

• Улучшения в анализе инфраструктуры (Enhanced Visibility):
  • Netflow от физических устройств теперь можно добавить в целях планирования безопасности и решения проблем для приложений, включая физические серверы. Кроме того, пользователи, у которых нет распределенного коммутатора vSphere Distributed Switch (vDS), могут использовать Netflow при проведении аудита виртуальной сети (Virtual Network Assessment).
  • Клиенты, работающие в AWS GovCloud, теперь могут использовать vRNI для планирования безопасности и траблшутинга в AWS окружении.
  • Добавлена поддержка решения Palo Alto Panorama 8, а также коммутаторов Arista и Juniper, что улучшает сбор информации в физической и виртуальной сетевой инфраструктуре.
• Функции быстрого решения проблем:
  • В разделе Flow analytics появилась информация о самых обменивающихся по сети системах, а также об активности новых систем за 24 часа, что позволяет быстрее идентифицировать и решать проблемы.
  • Новый виджет AWS Security Group быстро позволяет находить проблемы в инфраструктуре AWS.
  • Появилась поддержка групп безопасности и правил сетевого экрана решения NSX-T.
• Функции открытой платформы:
  • vRealize Network Insight 3.6 предоставляет публичный API для автоматизации рабочих процессов. Например, рекомендуемые правила сетевого экрана для приложения можно получить через vRNI и далее уже применить через решение NSX и фаерволы AWS.

Скачать VMware vRealize Network Insight 3.6 можно по этой ссылке.

Дункан Эппинг написал интересную заметку о максимальных настройках виртуальных машин, защищенных средствами кластера непрерывной доступности VMware Fault Tolerance.

Некоторые из вас знают, что у Fault Tolerance есть ограничения как по числу одновременно защищенных виртуальных машин на хосте, так и по числу виртуальных процессоров (vCPU) на один хост ESXi. Напомним, что эти ограничения были улучшены в VMware vSphere 6.0, теперь можно с помощью FT защищать машины с четырьмя vCPU, а всего таких машин может быть до четырех штук. Но при этом заявлено, что для FT не может быть более 8 vCPU на хосте (то есть 4 машины по 4 vCPU в каждой поддерживать не получиться).

Но это, оказывается, только в дефолтной конфигурации. Для регулирования этих параметров есть две расширенные настройки (Advanced Settings) кластера HA/DRS:

• das.maxftvmsperhost - максимальное число защищенных ВМ на хост (4).
• das.maxFtVCpusPerHost - максимальное число защищенных vCPU на хост (8).

Они по умолчанию равны значениям, описанным выше, но вы можете выставить свои значения - и это будет работать. Тогда откуда они взялись? Очень просто - инженеры взяли типовые нагрузки, посадили их на адаптер 10G и получили, что хост потянет где-то 8 vCPU для Fault Tolerance (4 машины по 2 vCPU). Это условие выполняется при старте машин пользователем, миграциях vMotion, а также механизмом DRS при расчете рекомендаций.

Но у вас своя инфраструктура (может уже и адаптеры 40 Gbps), поэтому вы можете использовать какие захотите разумные значения. Кстати, если вы поставите значение 0, то кластер VMware DRS будет полностью игнорировать данное требование к числу FT-машин на хост.

Но помните, что со стороны VMware превышение указанных значений не будет официально поддерживаемой конфигурацией.

На днях компания VMware начала тестировать новую версию своего фреймворка для управления виртуальной инфраструктурой и выпустила VMware PowerCLI Beta.

Как вы помните, в конце 2016 года VMware на сайте проекта VMware Labs опубликовала утилиту PowerCLI Core, которая позволяет пользователям применять те же самые командлеты PowerCLI на системах Linux, Mac и Docker, которые ранее были доступны только для Windows.

В новой бета-версии PowerCLI эта утилита будет не нужна, так как теперь PowerCLI будет работать на всех платформах в рамках единого пакета, а из состава продукта для платформ Linux и MacOS уйдет слово "Core". На данный момент эта бета была протестирована на следующих платформах:

• Windows
• CentOS 7 (тестирование еще в процессе)
• Ubuntu 16.04
• MacOS 10.12

В этой бета-версии на все платформы были портированы следующие модули:

• VMware.VimAutomation.Sdk
• VMware.VimAutomation.Common
• VMware.VimAutomation.Core
• VMware.VimAutomation.Vds
• VMware.VimAutomation.Cis.Core
• VMware.VimAutomation.Nsxt
• VMware.VimAutomation.Vmc
• VMware.VimAutomation.Storage
• VMware.VimAutomation.StorageUtil

Для MacOS и Linux вы увидите только перечисленные модули, остальные пока не доступны. Устанавливать их нужно так:

$installOrder = @(  
    "VMware.VimAutomation.Sdk",  
    "VMware.VimAutomation.Common",  
    "VMware.VimAutomation.Cis.Core",  
    "VMware.VimAutomation.Core",  
    "VMware.VimAutomation.License",  
    "VMware.VimAutomation.Vds",  
    "VMware.VimAutomation.Storage",  
    "VMware.VimAutomation.Cloud",  
    "VMware.VimAutomation.vROps",  
    "VMware.VimAutomation.PCloud",  
    "VMware.VimAutomation.Nsxt",  
    "VMware.VimAutomation.vmc"  
)  
$installOrder | %{install-module $_ -AllowPrerelease -repository PSGallery}  

Более подробную информацию о VMware PowerCLI Beta можно получить вот тут. Ну и вам надо знать, что бета работает только на PowerShell Core v6.0.1 (на версии 6.0.0 работать не будет).

С появлением таких решений, как VMware Virtual SAN и StarWind Virtual SAN, многие пользователи стали проявлять интерес к хранилищам на базе серверных систем, построенным полностью на флэш-накопителях. Само собой, это все работает очень быстро, но стоит приличных денег. Кроме того, предприятия используют и отдельные системы хранения данных All-Flash, что дает отличные результаты по IOPS, но для многих пока это стоит космических денег.

Вот, кстати, последний магический квадрант Gartner о производителях систем хранения на базе накопителей SSD:

Jerome Wendt, аналитик компании DCIG, написал интересную классификацию хранилищ данных All-Flash с примерами. Вот какие основные группы он выделяет:

1. Elastic all-flash arrays. Это дисковые массивы, которые изначально были запроектированы под флэш-хранилища. Это множество включает в себя такие модели, как Dell EMC XtremIO, Kaminario, Nimbus Data и Pure Storage, а аналитическая компания DCIG также включает туда массивы HPE Nimble и Dell EMC Isilon. Главная характеристика этой группы - это возможность горизонтального масштабирования, которое подразумевает рабочий процесс "set-it-and-forget-it" (то есть настроил и забыл).
2. Enterprise all-flash arrays. Это массивы корпоративного класса, которые, как правило, стоят весьма немалых денег. Эта группа представлена массивами Dell EMC VMAX, HPE 3PAR, Huawei OceanStor, NetApp AFF и Western Digital Tegile. В этих моделях есть как вертикальное (scale-up), так и горизонтальное (scale-out) масштабирование, а сами массивы заточены под выдачу максимальной производительности (1+ million IOPS). Самое главное - что эти массивы хорошо обрабатывают смешанные нагрузки (а не просто последовательное чтение или запись) по вводу-выводу в больших корпоративных окружениях (Enterprise-админы поймут, почему это самая важная характеристика).
3. General purpose all-flash arrays. Это множество представлено такими продуктами, как Dell EMC Unity, FUJITSU Storage ETERNUS AF Series, Hitachi Vantara VSP F series, Nexsan Unity и NEC Storage M Series. Это традиционные дисковые массивы с двумя контроллерами, которые были обновлены, чтобы обслуживать флэш-накопители. Главное преимущество этих систем - развитые системы управления, так как они прошли большой путь эволюции.
4. High performance all-flash arrays. Это отдельный класс дорогостоящих систем на базе флэш-памяти, которые только приходят на рынок. В качестве примера сейчас можно привести СХД E8 Storage, а позднее в этом году выйдет система от Kaminario. В этом классе количественная мера производительности уже на порядок выше - это 10+ миллионов IOPS, получаемых за счет использования технологии NVMe-oF на фронтенд-интерфейсах для хостов. Отметим, что внедрение этих хранилищ на практике пока затруднено, ввиду высокой цены и общей неготовностью инфраструктуры к обслуживанию таких хранилищ.
5. Utility all-flash arrays. Эта группа включает в себя такие СХД, как серию хранилищ HPE MSA, IBM FlashSystem 900, серию NetApp E-series и SanDisk Infiniflash. Это системы для организаций, которым необходимо посадить на дисковый массив только несколько приложений, которым необходим высокий уровень производительности и надежности. Эти хранилища продаются по привлекательной цене, но заточены под вполне определенные задачи и не подходят для сред с большим числом нагрузок. Кроме того, в этих СХД средства управления не позволяют делать многого.

Автор говорит еще о том, что в течение 5-10 лет появятся еще так называемые Composable Flash Arrays, которые заменят собой описанные пять типов массивов, но пока ситуация остается такой, какой она описана выше.

Осенью прошлого года мы писали о продукте VMware vRealize LifeCycle Manager в составе пакета vRealize Suite 2017, который позволяет автоматизировать установку, конфигурацию, апгрейд/патчинг, управление изменениями, исправление конфигурации и мониторинг состояния компонентов vRealize Suite из единой консоли с фокусом на исполнение бизнес-задач.

Недавно компания VMware выпустила обновление - vRealize Suite Lifecycle Manager (vRSLCM) 1.1. Давайте посмотрим, что нового появилось в этом решении:

1. Возможность сохранения "золотой конфигурации" в качестве бейслайна для инфраструктуры vRealize:

2. Отслеживание и мониторинг отклонений текущей конфигурации от заданного бейслайна:

3. Возможность исправления конфигурации (Remediate) в один клик:

4. Функция Delete Environment (позволяет настройить все с нуля):

Более подробная информация vRealize Suite Lifecycle Manager приведена тут и тут. Скачать vRSLCM 1.1 можно по этой ссылке.

Многие администраторы больших инфраструктур VMware vSphere используют стенсилы Microsoft Visio для создания различных диаграмм и схем в целях документирования текущего или будущего состояния инфраструктуры виртуализации. Также стенсилы и иконки используют консультанты и прочие ИТ-специалисты в своих презентациях PowerPoint.

Специально для них Ray Heffer обновил коллекцию "VMware Visio Stencils и иконки для презентаций PowerPoint", в которой масса полезных штук для составления схем и диаграмм (она составлена на базе графики различных производителей, не только VMware):

Скачать эти иконки можно в виде RAR-архива по этой ссылке.

Ну и вот еще список иконок для решений различных вендоров, которые использовались в качестве источников:

• Иконки Microsoft
• VMware icons and shapes: часть 1, часть 2, часть 3
• Иконки PowerPoint для NSX
• Графика Cisco
• Графика Google
• Графика Mozilla
• Графика Evernote
• Графика Oracle
• Графика Teradici
• Графика NVIDIA

Ну а вот наши посты по этой теме (поковыряйте, может что-то из этого еще актуально или обновилось):

• Бесплатные стенсилы для корпоративного датацентра от VMTurbo + обновленные стенсилы Veeam
• Стенсилы и иконки VMware Visio Stencils выпуск 4
• Новые стенсилы (Visio Stencils) от Veeam для документирования виртуальной инфраструктуры VMware vSphere и Microsoft Hyper-V
• Официальные и неофициальные стенсилы Microsoft Visio для документирования инфраструктуры VMware vSphere, VMware View и других продуктов
• Графика для VMware vSphere - иконки, visio стенсилы и boxshots

Ну и если здесь нет того, что вы считаете полезным - кидайте в комментарии.

Многие из вас знают про продукт для создания отказоустойчивых хранилищ StarWind Virtual SAN, являющийся лидером в сфере программных iSCSI-хранилищ под виртуализацию VMware vSphere и Microsoft Hyper-V.

Одной из возможностей данного решения является функция inline-дедупликации хранимых данных, которая позволяет существенно экономить дисковое пространство на конечных блочных носителях. Напомним, что еще в 2011 году мы писали о дедупликации StarWind, но с тех пор технология существенно ушла вперед, и вот уже несколько лет она работает надежно и эффективно.

Для тех, кто хочет заранее узнать, сколько именно места можно сэкономить с помощью продукта Virtual SAN, компания StarWind выпустила бесплатную утилиту StarWind Deduplication Analyzer, которая помогает вам проанализировать текущую структуру хранения виртуальных машин и получить отчет о потенциальной экономии. Запускать утилиту можно как для всего хранилища в целом, так и для отдельных виртуальных машин, чтобы идентифицировать ВМ, которые лучше всего ужимаются вследствие дедупликации на диске.

Как мы видим, StarWind использует 4k-блоки, которые сейчас являются стандартом де-факто для достижения наибольшей эффективности дедупликации.

По итогам работы утилиты будет выведен отчет о возможной экономии дискового пространства и количестве уникальных блоков на диске, который можно сохранить и распечатать:

Кстати, на скриншоте показан пример из реальной жизни, где коэффициент дедупликации оказался примерно равен 50%, то есть можно сэкономить где-то половину дискового пространства при хранении ВМ виртуального датацентра.

Работает утилита достаточно быстро, а главное, что пользоваться ей очень просто - выбираете папку и нажимаете кнопку Scan. При этом Deduplication Analyzer не требует установки и работает сразу при запуске скачанного файла.

Загрузить StarWind Deduplication Analyzer можно по этой ссылке.

В декабре прошлого года компания Citrix выпустила обновление своей серверной платформы виртуализации Citrix XenServer 7.3. Напомним, что о версии XenServer 7.2 мы писали летом прошлого года вот тут.

Давайте посмотрим, что нового появилось в XenServer 7.3:

• Улучшенная подсистема безопасности для виртуальных машин Windows за счет поддержки платформы Bromium.
• Changed Block Tracking API (для инкрементального резервного копирования только изменившихся блоков ВМ).
• Поддержка новых гостевых ОС и расширение поддержки старых.
• Поддержка тэгирования VLAN на интерфейсах management и storage network.
• Реализация IGMP snooping для режима IPv4 multicast.
• Поддержка SMB v3.0 для репозиториев (SR) с ISO-образами.
• Улучшения в продукте XenServer Conversion Manager для миграции виртуальных машин с платформы VMware.
• Локализация алертов Email Performance Alerts.
• Поддержка BIOS Asset Tags.
• Интеграция с решением Citrix Director.
• Возможность поддержки XenDesktop Tablet Mode (предоставляет функции интерфейса Windows 10 Continuum в виртуальных десктопах).

Но самое интересное - это то, что Citrix решила убрать некоторые возможности из бесплатной версии, переместив их в издание Standard, которое стоит денег. Вот чего лишатся пользователи бесплатного XenServer, начиная с версии 7.3:

• Технология распределения памяти Dynamic Memory Control.
• Миграция хранилищ Xen Storage Motion.
• Интеграция с сервисами Active Directory.
• Ролевая модель доступа (Role Based Access Control).
• Высокая доступность (High Availability).
• Технология проброса графического адаптера GPU Pass-Through.
• Средство отказо- и катастрофоустойчивости Site Recovery Manager (Disaster Recovery решение).
• Мастер апгрейда пулов XenCenter Rolling Pool Upgrade.
• Максимальный размер пула (кластера) ограничен 3 хостами (текущие пулы с большим числом хостов продолжат работать, но туда нельзя будет добавлять новые хосты).

Дофига! Что это? Правильно - кастрация бесплатного решения. Таблицу со сравнением функциональности бесплатного и коммерческих изданий нового Citrix XenServer 7.3 можно скачать по этой ссылке.

Ну а сам Citrix XenServer 7.3 можно загрузить вот тут. Release Notes доступны здесь.

У некоторых администраторов VMware vSphere время от времени возникает проблема с горячей миграцией vMotion виртуальных машин, например, когда они выводят хост в режим обслуживания (Maintenance Mode). vMotion зависает на 21%, и на vCenter Server появляется ошибка наподобие такой:

Failed waiting for data. Error 195887137. Timeout. vMotion migration failed to send buffer to remote host. vMotion migration failed writing stream completion.

Еще одно сообщение об ошибке в этом случае выглядит вот так:

The vMotion failed bacause the destination host did not receive data from the source host on the vMotion network. Failed to initialize migration at source. Error 195887109.

На панели задач мы видим вот такую картину:

Если посмотреть на лог-файлы, то там не обнаруживается никаких проблем. Но подобного рода ошибки, если внимательно поискать их в VMware KB, указывают на разные сконфигурированные значения MTU пакета в виртуальной инфраструктуре и на портах физических коммутаторов. Например, на vSphere Distributed Switch для порта VMkernel, через который идет миграция vMotion, размер MTU у вас выставлен в 9000 (для поддержки Jumbo Frames), а вот на на порту свича - 1500.

Поэтому всегда проверяйте, чтобы размер MTU был одинаковым на всех компонентах физической и виртуальной инфраструктуры - vDS и портах коммутатора. Более подробно о настройке Jumbo frames написано в KB 1038827.

Недавно мы писали о недавнем обновлении продукта для виртуализации и агрегации сетей датацентра VMware NSX for vSphere 6.4, а на днях блогер Sam McGeown опубликовал интересную диаграмму соединений и портов VMware NSX 6.x Network Communications Diagram, на которой в центре расположено решений NSX Manager (главный управляющий компонент), а остальные компоненты сетевой инфраструктуры указаны с ведущими к ним коммуникациями по соответствующим портам:

Пока данная диаграмма показывает только соединения в рамках одной площадки, но автор обещает вскоре ее обновить, включив туда Cross vCenter коммуникации.

Загрузить диаграмму:

• PNG: NSX Communication Ports
• PDF: NSX Communication Ports

Многие из вас хотя бы раз задумывались о том, сколько виртуальных машин должно в среднем приходиться на один хост, а кроме того, в частности, сколько виртуальных процессоров (vCPU) могут исполняться на физических процессорах (pCPU) хост-сервера VMware ESXi.

На этот счет системные архитекторы часто дают следующие рекомендации (в соответствии с критичностью нагрузок в кластере):

• Tier 1 cluster (mission-critical приложения) - соотношение 1:1 vCPU / pCPU.
• Tier 2 cluster (business-critical приложения) - соотношение 3:1 vCPU / pCPU.
• Tier 3 cluster (инфраструктурные и обеспечивающие приложения) - соотношение 5:1 vCPU / pCPU.
• Tier 4 cluster (виртуальные десктопы) - соотношение 10:1 vCPU / pCPU.

Это общие рекомендации и, конечно же, не железные правила - отталкиваться нужно от имеющегося оборудования и характера нагрузок в виртуальных машинах.

Для того, чтобы регулировать это соотношение со стороны кластера балансировки нагрузки VMware DRS есть 2 специальные расширенные настройки:

• MaxVcpusPerClusterPct - регулирует соотношение vCPU/pCPU на уровне всего кластера, не привязываясь к конкретным хостам ESXi (то есть сумма vCPU всех машин делится на сумму pCPU всех хостов).
• MaxVCPUsPerCore - регулирует соотношение vCPU/pCPU на уровне каждого из хостов ESXi, то есть ни на одном из них это соотношение не может быть превышено.

Указываются эти расширенные настройки в разделе Configuration Parameters в vSphere Web Client при настройке DRS-кластера:

Также их можно задать и в HTML5-клиенте vSphere Client:

Но самое интересное - это то, что в vSpher Web Client эта настройка есть в GUI и регулирует параметр MaxVcpusPerClusterPct на уровне всего кластера (можно задать процент от 0 до 500, но разумно задавать значения от 100 до 500, если задать 500 - число vCPU может быть больше pCPU в пять раз):

А вот в vSphere Client - эта настройка уже MaxVCPUsPerCore, то есть задание CPU Overcommitment на уровне каждого из хостов ESXi, о чем и написано в интерфейсе:

Кстати, выставить эту настройку можно в диапазоне от 0 до 32.

Пару недель назад мы писали о новых возможностях последних версий HTML5-клиента для управления виртуальной инфраструктурой VMware vSphere Client 3.31-3.32, а на днях компания VMware выпустила очередное обновление vSphere Client 3.33, где появилось немало новых возможностей (а не как обычно).

Давайте посмотрим, что нового в этом обновлении:

• Поддержка устройств PCI и Shared PCI для виртуальных машин.
• Мастер создания нового виртуального сервиса (vApp).
• Мастер клонирования vApp.
• Перемещение vApp в между хостами и кластерами.
• Возможность копирования customization specification виртуальной машины на другой сервер vCenter с возможностью изменения имени и описания спецификации.
• Действие Synchronize Licenses (ранее оно называлось Import License Keys Data).
• Детали об имеющихся ассетах и лицензиях.
• Возможность изменять VM Advanced configurations в настройках виртуальной машины (пункт Edit Settings).
• Изменение ярлыков для операций с состоянием ВМ (Power Operations) в разделе VMware tools в опциях Edit Settings для виртуальной машины.
• Изменение максимального количества сессий VMRC для виртуальной машины в настройках (Edit Settings).

В целом, не так уж и мало для очередного обновления. Скачать VMware vSphere Client 3.33 можно по этой ссылке.

На днях компания VMware обновила свое основное решение для виртуализации и агрегации сетей виртуального датацентра до версии VMware NSX for vSphere 6.4. Напомним, что о возможностях прошлой версии NSX 6.3 мы писали в начале прошлого года.

Давайте посмотрим, что нового появилось в NSX 6.4:

1. Механизм Context-aware micro-segmentation.

Как знают администраторы NSX, эта платформа уже давно не оперирует понятиями IP-адресов и базовой сетевой идентификацией, вместо этого NSX позволяет управлять сетями на базе политик, в составе которых такие настройки, как операционная система, имена виртуальных машин и приложения. Это позволяет более гибко оперировать метриками.

Теперь NSX позволяет создавать и управлять политиками на базе контекстов приложений (это и есть микросегментация) - сетевом (на уровне 7 модели OSI), пользовательском (ID, сессия RDSH и прочее), а также рабочей нагрузки (тэги, группы безопасности):

Отсюда следуют 3 новых возможности:

• Network flow app detection и управление на уровне 7.

NSX реализует технологию глубокого анализа Deep Packet Inspection (через заголовки пакетов TCP/UDP) для идентификации приложения в сетевом трафике. Это избавляет от необходимости вручную идентифицировать приложения датацентров и задавать политики для различных приложений, которые обнаруживаются по их сигнатурам.

• Virtual Desktop and Remote (RDSH) Session Security per User.

Одна из фишек микросегментации - это защита виртуальных ПК, поскольку несколько сессий исполняется на одном хост-сервере и данные пользовательских ПК должны быть надежно защищены друг от друга. NSX работает с политиками безопасности на уровне виртуальных машин и пользователей, что позволяет создавать разграничения трафика в таких VDI-средах, как VMware Horizon, Citrix XenDesktop и Microsoft RDSH.

• Улучшения Application Rule Manager.

Теперь это средство предлагает не только сами правила для приложений, но и рекомендует группы безопасности, чтобы наиболее эффективно организовать микросегментацию датацентра.

2. Поддержка vSphere Client и HTML5.

Интерфейс NSX был полностью переработан, чтобы поддерживать vSphere Client на базе технологии HTML5 (плагин называется VMware NSX UI Plug-in for vSphere Client). Например, Upgrade Coordinator был также полностью переосмыслен, и теперь можно наслаждаться новым видом рабочего процесса по планированию и обновлению NSX:

Помимо этого, было существенно улучшено меню навигации в продукте.

3. Улучшения сервисов безопасности.

• Identity Firewall - теперь поддерживаются пользовательские сессии к виртуальным ПК и серверам RDSH, а также выборочная синхронизация с Active Directory в целях ускорения процесса.
• Distributed Firewall - теперь он может быть создан из набора stateless-правил на уровне секции DFW. Кроме того, поддерживается реализация IP-адресов на уровне гипервизора, а также проверка вхождения IP-адресов в группы безопасности, кластеры, хосты или пулы ресурсов.
• Улучшения механизмов IP discovery.
• Улучшения анализа трафика гостевых ОС (Guest Introspection).

4. Улучшения средств управления и средств решения проблем.

• Новый дэшборд HTML5, доступный по дефолту.
• Новый дэшборд System Scale, который показывает текущий масштаб системы на фоне максимумов конфигурации, поддерживаемых NSX.
• Улучшения Guest Introspection - такие фичи, как EAM status notification, мониторинг процесса апгрейда, кастомные имена для SVMs, выделение дополнительной памяти и т.п.
• Единый интерфейс командной строки для logical switch, logical router и edge distributed firewall.
• Новая вкладка Support Bundle позволяет сгенерировать пакет данных для техподдержки, а также наблюдать за ходом выполнения этого процесса.
• Вкладка Packet Capture - она позволяет в ручном режиме перехватывать и анализировать пакеты.
• Возможность включения режима Controller Disconnected Operation (CDO), который позволят избежать проблем при временной недоступности сетевого соединения с основной площадкой.
• Поддержка до 5 Syslog-серверов.
• Поддержка форматов JSON и XML.
• Множество улучшений NSX Edge, которые описаны вот тут.

Загрузить VMware NSX for vSphere 6.4 можно прямо сейчас по этой ссылке.

Почти все из вас в курсе, что недавно в процессорах Intel были найдены уязвимости Meltdown и Spectre. Недавно мы писали о том, то компания VMware выпустила патчи для хост-серверов VMware ESXi, а также для управляющего сервера vCenter. Вильям Лам даже написал скрипт PowerCLI для проверки накаченных обновлений на хосты и виртуальные машины.

Но...18 января VMware, получив некую "важную информацию" от Intel, отозвала выпущенные патчи и опубликовала специальную KB 117649, в которой описала сложившуюся ситуацию, не особенно ее проясняя. Пока мы ждем патчей от VMware и Intel, можно взглянуть на некоторые результаты тестов производительности (раз и два), где показано, как исправления микрокода серверов от описанных уязвимостей негативно влияют на производительность:

Говорят, что падение производительности для тяжелых нагрузок (особенно по вводу-выводу) может составить от 5% до 30%, что как бы очень много.

В связи с этими событиями (последствия от которых еще проявят себя в ближайшие недели), компания Login VSI сделала специальную бесплатную лицензию на свое одноименное средство тестирования (мы писали об одной из версий тут). Запросить бесплатную лицензию на инструмент Login VSI можно по этой ссылке. Она, кстати, абсолютно ничем не ограничена - ни числом хостов, ни виртуальных машин в вашей виртуальной инфраструктуре, а для тестирования доступны все рабочие нагрузки.

Единственное ее ограничение - бесплатная версия прекратит работать 31 марта этого года. С помощью Login VSI вы можете протестировать производительность таких платформ, как Citrix XenApp, XenDesktop, Microsoft RDS и, конечно же, VMware Horizon View. 

В целом, влияние обновлений безопасности на производительность особенно чувствительно именно для VDI-инфраструктур, где коэффициент консолидации виртуальных машин на хостах существенно выше, чем в серверной среде.

Запросить бесплатную лицензию на Login VSI можно здесь.

Компания VMware на днях объявила о доступности для загрузки обновленной версии решения VMware Integrated OpenStack 4.1. Напомним, что о версии 4.0 данной платформы мы писали вот тут осенью прошлого года. Данный релиз поддерживает не только платформа vSphere, но и такие продукты, как vSphere, vSAN и NSX V|T (включая решение NSX-T LBaaSv2). Облачным администраторам в этом обновлении понравятся средства расширенного управления, а администраторам хранилищ Kubernetes - различные утилиты для автоматизации рабочих процессов.

В основе архитектуры VMware лежит виртуальный модуль vSphere OpenStack Virtual Appliance (VOVA), позволяющий построить инфраструктуру OpenStack на базе платформы виртуализации VMware vSphere. Сам же VMware Integrated OpenStack (VIO) - это специальный дистрибутив, поддерживаемый VMware, оптимизированный для работы на базе инфраструктуры SDDC (software defined data center).

Давайте посмотрим на новые возможности VMware Integrated OpenStack 4.1:

• Поддержка последних продуктов VMware. VIO 4.1 полностью поддерживает VMware vSphere 6.5 U1 (подробнее тут), vSAN 6.6.1, VMware NSX for vSphere 6.3.5 и VMware NSX-T 2.1 (подробнее тут).
• Public OMS API – появился API для управляющих серверов, который может быть использован для автоматизации и обслуживания жизненного цикла компонентов инфраструктуры OpenStack. Например, можно развернуть кластер OpenStack, остановить или запустить его, собрать бандлы для техподдержки и т.п. Вы также можете использовать Swagger UI для проверки валидности API и его спецификаций. Вот основные адреса для доступа:

API Base URL: https://[oms_ip]:8443/v1

Swagger UI: https://[oms_ip]:8443/swagger-ui.html

Swagger Docs: https://[oms_ip]:8443/v2/api-docs

• HAProxy Rate Limiting – облачный администратор теперь имеет возможность ограничить публичный доступ к API в определенном объеме. Это настраивается в шаблоне custom.yml.
• Neutron QoS – В VIO 4.1 облачный админ может использовать Neutron QoS для создания профиля QoS и его маппинга к портам или логическому коммутатору. При этом виртуальная машина при таком подключении будет наследовать политику портов.
• Native NSX-T Load Balancer as a Service (LBaaS) – В VIO 4.1 NSX-T LBaaSv2 может быть развернут с использованием как Horizon, так и Neutron LBaaS API.  Каждый балансировщик обязательно должен быть замаплен к логическому маршрутизатору NSX-T Tier 1 logical router (LR).
• Multiple domain LDAP backend – поддерживается SQL, а также один или несколько доменов как identity source (всего до 10 доменов). Каждый домен может иметь свой бэкенд аутентификации (поддерживается Active Directory и OpenDirectory).

Отдельно надо упомянуть новые фичи NFV и Kubernetes:

• VIO-in-a-box (так называемый Tiny deployment). Все компоненты VIO можно развернуть на одном физическом сервере. Его можно развернуть в ручном режиме или через OMS API. 
• CPU Policy for Latency Sensitivity Workflows – рабочие нагрузки, чувствительные к задержкам (Latency), часто требуют заранее выделенных ресурсов CPU, памяти и сети. В VIO 4.1 появилась поддержка политик в стиле Nova - ‘hw:cpu_policy”.  Эта политика мапит vCPU к конкретному инстансу процессора.
• Networking Passthrough – В VIO 4.1появился фреймворк на базе Neutron для проброса физических сетевых устройств в виртуальные машины.  Это позволяет с помощью Neutron настраивать MAC, IP и QoS сетевого устройства проброшенного через passthrough. Потом этот подход будет применен ко всем типам  passthrough-устройств.
• Enhanced Kubernetes support – VIO 4.1 идет вместе Kubernetes версии 1.8.1.  Также доступна интеграция с решениями Helm и Heapster. VIO 4.1 совместно с решением NSX-T2.1. также позволит использовать сетевые политики безопасности Kubernetes.
• VIO Kubernetes Support Bundle –  с помощью одной команды, указав начальную и конечную даты, можно собрать логи со всех компонентов, необходимые для анализа и решения проблем со всей инфраструктурой. Это позволяет легко и просто открыть тикет в техподдержке сервис-провайдера.
• VIO Kubernetes Log Insight Integration – как часть создания кластера Kubernetes, облачный админ может указать адрес сервера Log Insight в качестве внешней системы логгирования (пока только один сервер).
• VIO Kubernetes Control Plane Backup / Restore –  админ Kubernetes может делать резервные копии на уровне кластера через машину VIOK management VM. Бэкапы складываются в файлы tar.

Начать знакомство с VIO можно с прохождения лабораторной работы онлайн по этой ссылке: VMware Integrated OpenStack Hands-on Lab. Скачать VMware Integrated OpenStack 4.1 можно по этой ссылке.

Как вы знаете, механизм динамической балансировки нагрузки VMware DRS используется для того, чтобы в условиях неравномерной нагрузки на хост-серверы VMware ESXi выравнивать ее за счет дачи рекомендаций по миграции виртуальных машин средствами vMotion на другие хосты, либо автоматического выполнения этих рекомендаций.

Давайте посмотрим как Distributed Resource Scheduler работает с оперативной памятью. В кластере DRS есть такая настройка "Memory Metric for Load Balancing", которая отключена по умолчанию, и если почитать к ней описание, то становится понятно, что DRS по умолчанию руководствуется параметром Active memory для балансировки.

У машины есть три основных параметра памяти, учитываемых DRS - это Active, Consumed и Configured Memory:

• Configured - это память, указанная в настройках виртуальной машины, то есть ее максимальное значение.
• Consumed - это память, которая использовалась виртуальной машиной с момента ее загрузки (а вы знаете, что при загрузке операционная система обращается к большему объему памяти, чем затем ее использует).
• Active - это активные страницы памяти (RAM), которые сейчас используются гостевой ОС.

На картинке ниже показан пример - у машины 16 ГБ памяти, при этом при загрузке она наинициализировала страниц памяти на 12 ГБ, а активно использует только 5734 МБ.

Для того чтобы подчитывать используемую память, планировщик DRS подсчитывает working set из страниц Active Memory и прибавляет к нему 25% от разницы между Consumed и Active (это называется Idle Consumed Memory) на незапланированные резкие изменения нагрузки - и это число использует в своих вычислениях балансировки кластера:

В данном случае будет использоваться значение 5734+0,25*(12288-5734) = 7372,5 МБ (на картинке 7373 МБ). Кстати, это еще не все - к машине с памятью в 16 ГБ прибавляются накладные расходы (Overhead) в размере 90 МБ, поэтому DRS в своих вычислениях будет использовать значение 7373+90 = 7463 МБ.

Если же включить настройку DRS-кластера, упомянутую выше, то DRS в своих вычислениях будет использовать Consumed Memory и также прибавлять Memory Overhead:

В обновлении vSphere 6.5 update 1d клиент позволяет вам просматривать как метрику Active Memory, так и Consumed Memory.

Вот так выглядит картинка для сбалансированного кластера DRS (рекомендаций и ошибок нет):

Кстати, если вы посмотрите на Active Memory сбалансированного кластера, то там вполне может быть дисбаланс:

В этом нет ничего страшного, так как машины используют менее 20% active memory от памяти хоста, всем памяти хватает, и DRS решает, что балансировать машины в таком случае - это только тратить ресурсы CPU и сети на vMotion.

Переключимся теперь на Consumed memory:

Тут мы видим большой дисбаланс и разница между хостами более 20% от значений Consumed memory на них. Поэтому если мы включим настройку "Memory Metric for Load Balancing", то кластер DRS начнет работу по миграции виртуальных машин между хост-серверами. Итогом будет вот такая картина:

Вывод тут вот какой. Если у вас кластер работает без оверкомита (non-overcommitted) и есть большой запас по RAM на хостах, то, возможно, вам и следует поставить настройку "Memory Metric for Load Balancing", чтобы DRS балансировал хосты по consumed memory, а сами рекомендации по миграциям, например, можно применять в ручном режиме, чтобы контролировать ситуацию.

Многие из вас знают, что одной из новых возможностей решения для организации отказоустойчивых кластеров хранения VMware vSAN стали проактивные тесты, которые доступны через VMware vSphere Web Client. Раньше их было три штуки:

Но недавно некоторые из вас, возможно, заметили, что в новой версии VMware vSAN (которая доступна с VMware vSphere 6.5 Update 1 Patch 02) остался только одиноко болтающийся тест на создание виртуальной машины:

Дункан Эппинг пишет, что это обусловлено двумя факторами:

• Тест Multicast performance ушел, так как мультикаст-режим был убран из VMware vSAN (еще в версии vSAN 6.6), соответственно, ушел и тест на его производительность. Теперь когда вы используете vSAN в режиме юникаст, то тест показан не будет, но если будете использовать все же мультикаст - тест появится.
• А вот тест Storage Performance ушел вот почему: у VMware есть методика тестирования HCI Bench, которая позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ vSAN, а также других конфигураций виртуальной инфраструктуры. Это очень гибкий инструмент, который позволяет проводить наиболее точное тестирование и настраивать различные аспекты методики и среды тестирования. Соответственно, VMware решила поддерживать только один инструмент, а Storage Performance Test убрать из клиента для управления виртуальной инфраструктурой.

Недавно мы писали, что в начале года компания VMware выпустила обновления своей платформы виртуализации настольных ПК предприятия - VMware Horizon 7.4. Параллельно с апдейтом этого VDI-решения было проведено и обновление клиентов, в частности вышел VMware Horizon Client 4.7 for iOS, работающий на устройствах iPhone и iPad.

Давайте посмотрим, что нового появилось в Horizon Client 4.7:

• Улучшения восстановления соединения VMware Blast. Эта функция была улучшена в плане надежности механизмов пересоединения и повторной передачи при временных сбоях в сети. В большинстве таких случаев приложения продолжают работать после короткой паузы. Для приложений чувствительных ко времени отклика VMware Blast перезапускает сессию.
• Поддержка Derived credentials (аутентификация через одноразовые пароли) для аутентификации на удаленном десктопе. Для этого поддерживается решение Purebred.
• Драг энд дроп текста и картинок. Эта функция показана в видео ниже. Можно перетаскивать объекты из клиентского устройства в опубликованное приложение или в открытое приложение на виртуальном десктопе.

А вот так это работает с клавиатурой и мышью Swiftpoint GT:

• Генерация ярлыков и ссылок на сайты. Теперь можно перетащить ярлык сервера, десктопа или приложения на другое приложение, чтобы сгенерировать URI. Также можно перетащить имя сервера на страницу Servers, чтобы присоединиться к нему.

• Поддержка аутентификации Face ID. Теперь можно выбрать этот способ аутентификации на айфонах и других будущих устройствах с поддержкой Apple Face ID.

Как всегда клиент VMware Horizon Client 4.7 for iOS доступен на общей странице загрузки клиентов VMware Horizon.

Уважаемые коллеги!

Приглашаем на интереснейший вебинар «VMware vCloud Extender – новейший инструмент построения гибридных облаков для vSphere 6.5». Про vCloud Extender мы уже писали вот тут. Это бывший продукт vCloud Connector, сейчас vCloud Extender позволяет пользователям облачных инфраструктур бесплатно перенести свои онпремизные виртуальные машины в облако сервис-провайдеров IaaS.

Будет проведён краткий обзор функционала VMware vCloud Extender, существенно упрощающего и расширяющего возможности миграции сервисов в облако, а также решающий задачи обеспечения высокой доступности для ЦОД, рассмотрены наиболее характерные сценарии его применения. Кроме того, вас ждёт живая демонстрация продукта на платформе VMware vSphere 6.5 от Облакотеки.

Вебинар будет интересен прежде всего техническим руководителям и специалистам компаний, которые только планируют или уже активно используют для своих нужд облачные среды на платформе VMware.

Приходите - будет действительно интересно, живое демо продукта и разъяснение технических моментов по продукту vCloud Extender, о которых вы часто спрашиваете.

Присоединяйтесь к нам на нашем мероприятии, будем рады общению!

На днях мы писали о том, что компания VMware выпустила обновления VMware vCenter и ESXi, закрывающие потенциальную угрозу безопасности Spectre (она же Hypervisor-Assisted Guest Mitigation - CVE-2017-5715), которая недавно была обнаружена в процессорах Intel. Для закрытия уязвимости нужно обновить не только серверы ESXi и vCenter, но и микрокод (BIOS/Firmware) серверов (более подробная информация также приведена в KB 52085).

На днях наш читатель Сергей прислал ссылку на скрипт от Вильяма Лама, который позволяет провести проверку компонентов виртуальной инфраструктуры VMware vSphere на данную уязвимость. Этот PowerCLI-скрипт содержит две функции:

• Verify-ESXiMicrocodePatchAndVM
• Verify-ESXiMicrocodePatch

Первая функция позволяет проверить хосты ESXi и виртуальные машины и сгенерировать отчет в разрезе виртуальных машин. Если в колонке Affected стоит значение False - значит обновления и микрокода сервера, и хоста ESXi были применены, а сами ВМ и хост-сервер не подвержены уязвимости Spectre.

Вторая функция проверяет только, что на хостах ESXi накачено обновление как микрокода, так и самого гипервизора ESXi, который видит обновленные CPU features.

Функция Verify-ESXiMicrocodePatchAndVM может быть запущена тремя способами:

• Без параметров - проверяется все окружение VMware vSphere и все виртуальные машины в нем.
• С параметром - ClusterName - проверяется конкретный кластер и всего его хосты и ВМ.
• С параметром - VMName - проверяется только конкретная ВМ и ее хост, соответственно.

У функции Verify-ESXiMicrocodePatch также есть три способа вызова:

• Без параметров - проверяются все хост-сервера в инфраструктуре vCenter.
• С параметром - ClusterName - проверяется конкретный кластер и всего его хосты.
• С параметром - VMHostName - проверяется конкретный хост-сервер ESXi.

Скачать этот PowerCLI-сценарий можно по этой ссылке: VerifyESXiMicrocodePatch.ps1.

Кстати говоря, этот скрипт был добавлен в полезный скрипт vCheck, который перед Новым годом обновился до версии 6.25, скачать его можно вот тут - https://github.com/alanrenouf/vCheck-vSphere.

На днях компания VMware выпустила обновленную версию решения для виртуализации и доставки виртуальных ПК и приложений предприятия - VMware Horizon 7.4. Напомним, что предыдущее обновление этого продукта VMware Horizon 7.3.1 вышло осенью прошлого года.

Давайте посмотрим, что нового появилось в новой версии этой платформы для организации VDI-инфраструктуры:

1. Функция Session Collaboration.

Это средство для совместной работы - пользователь просто вызывает диалог шаринга сессии и генерирует линк на нее. После этого линк можно послать по почте, кинуть в скайп или передать еще каким-либо образом.

При этом получивший экран пользователь также может расшарить его, а изначальный юзер может передать управление любому из них.

Для работы этой возможности нужно включить ее на уровне пула виртуальных ПК или фермы серверов RDSH:

Требования к фиче Session Collaboration:

• Протокол VMware Blast Extreme.
• Клиент Horizon Client 4.7 (для Windows, Mac или Linux), а также HTML Access 4.7.
• Максимум 5 одновременных пользователей по умолчанию (это можно увеличить).
• Агент Horizon Agent 7.4 для VDI или RDSH.
• Сервер Horizon 7.4 Connection Server.
• Лицензия на издание Horizon 7 Enterprise Edition.

2. Instant Clones for Linux.

Теперь функция мгновенных клонов доступна и для Linux-систем. Для ее работы должны быть выполнены следующие требования:

• Плавающий (floating) пул десктопов Instant-clone.
• Версия Horizon 7.4 Connection Server и Linux Agent.
• Версия Ubuntu 14.04 или 16.04.
• Интеграция с Active Directory, предоставляемая Power Broker Identity Services Open (PBISO) v8.5.6 или более поздней версией.

3. Фермы RDSH Instant-Clone Farms с поддержкой vGPU.

Теперь фермы серверов RDSH могут быть с поддержкой технологии NVIDIA vGPU. Они могут в полной мере получить преимущества технологии Instant Clone.

На данный момент поддерживаются архитектуры графических карт NVIDIA M10, M60 и P40.

4. Улучшения RSDH Published Applications.

В этой категории были сделаны следующие улучшения:

• Поддержка Hardware GPU для Windows Server 2016.
• Функция USB AutoConnect: позволяет USB-устройствам автоматически подключаться при следующем запуске удаленного приложения.
• Улучшенная производительность запуска приложений - теперь время логина в published applications стало значительно меньше.
• Улучшенный механизм Empty-Session Timeout - теперь можно ставить нулевой таймаут при отключении RDSH-сессий.

5. Улучшенная точность цветов для кодирования H264.

Иногда в сессии кодека H.264 при работе схемы 4:2:2 chroma subsampling могут быть проблемы:

Для улучшения ситуации можно использовать цветовую схему YUV 4:4:4 вместо 4:2:2. Это дает большую ясность восприятия текста, как в примере слева на картинке выше. Включается это в настройках шаблона Blast Extreme ADMX (файл vdm_blast.admx).

5. Улучшения продукта Virtualization Pack for Skype for Business, Update 3.

Напомним, что о прошлых улучшениях мы писали вот тут и тут. Теперь из нового появилось следующее:

• Поддержка клиента Horizon 7 для Mac, включая HID-устройства и аппаратные камеры H.264.
• Интеграция с Microsoft Office - это включает в себя Microsoft SharePoint, Yammer, Microsoft Word и Microsoft Outlook.
• Функция Call Delegation - пользователи могут принимать звонки от имени кого-то или в дополнение к чьему-то вызову (также можно звонить от имени кого-то).
• Функция Call via X (из дома/работы) - пользователь может звонить как внутренний абонент, а также как внешний пользователь.
• Функция Active Speaker Identification - при конференц-звонках выводится видеопоток того, кто говорит в данный момент.
• Функция Volume Control from Remote Desktop - теперь пользователь может изнутри гостевой ОС регулировать громкость звонка.
• Группы ответа (Response Groups) - маршрутизация вызовов в группе пользователей (например, если кому-то звонят, то телефон звонит для всей группы).

6. Улучшения Horizon Client for Chrome OS.

Клиент для хромбуков получил следующие улучшения:

• Поддержка многомониторных конфигураций.
• Несколько одновременных сессий для десктопов и приложений Horizon 7 в бесшовных окнах.
• Drag and drop картинок и текста из телефонов Android в виртуальные машины.

Обо всех прочих улучшениях клиента Horizon Client 4.7 читайте в документации.

Скачать VMware Horizon 7.4 можно по этой ссылке. Release notes доступны тут. А клиентов как всегда можно скачать здесь.